Medical device with context-specific interfaces

ABSTRACT

A method for displaying information and receiving inputs with a medical device includes displaying a first interface on a display of the medical device, receiving various inputs from a user, displaying a second interface on the display of the medical device, and receiving vital signs data from the patient using the second interface. The first interface includes a login area including one or more prompts for information identifying a user of the medical device and profile selection area including two or more profiles offered by the medical device. The method further involves receiving user identifying information from the user via the login area, confirming the user identifying information, activating the profile selection area in response to confirming the user identifying information, receiving a profile selection from the user via the profile selection area, and receiving patient identification information from the user with the medical device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/535,534, filed Nov. 7, 2014, entitled, “Medical device withcontext-specific interfaces.” The disclosure of this priorityapplication is hereby incorporated by reference in its entirety into thepresent application.

BACKGROUND

As the amount of information that is captured by a medical deviceincreases, the complexity of using the device also increases. Such usecan be complicated by a failure to understand how the device iscurrently configured to operate. Further, a user can be confused aboutwhat information is needed to complete a medical record. Suchcomplexities can make the use of the medical device more difficult andundermine the efficiencies associated with the electronic capture andretention of medical data.

SUMMARY

In one aspect, a medical device includes: a processor; a display; andmemory encoding instructions that, when executed by the processor, causethe processor to create an interface on the display, the interfaceincluding: a login area including one or more prompts for informationidentifying a user of the medical device; and a profile selection areaincluding two or more profiles offered by the medical device, whereineach of the profiles is a series of tasks to be performed by the medicaldevice, and a description of each profile is provided in the profileselection area.

In another aspect, a medical device includes: a processor; a display;and memory encoding instructions that, when executed by the processor,cause the processor to create an interface on the display, the interfaceincluding: a vital signs area programmed to display data associated witha plurality of vital signs for a patient; and an additional parametersarea programmed to capture one or more additional parameters associatedwith the vital signs displayed in the vital signs area.

In yet another aspect, a medical device includes: a processor; adisplay; and memory encoding instructions that, when executed by theprocessor, cause the processor to create an interface on the display,the interface including: a login area including one or more prompts forinformation identifying a user of the medical device; a profileselection area including two or more profiles offered by the device,wherein each of the profiles is a series of tasks to be performed by themedical device, and a description of each profile is provided in theprofile selection area; a vital signs area programmed to display aplurality of vital signs associated with a patient; and an additionalparameters area programmed to capture one or more additional parametersassociated with the vital signs displayed in the vital signs area.

DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a block diagram of a wireless ambulatory care system.

FIG. 2 illustrates an example medical device of the system of FIG. 1.

FIG. 3 illustrates another example medical device of the system of FIG.1.

FIG. 4 illustrates an example login and profile selection interface forthe medical device of FIG. 3.

FIG. 5 illustrates another view of the interface of FIG. 4.

FIG. 6 illustrates another view of the interface of FIG. 4.

FIG. 7 illustrates another view of the interface of FIG. 4.

FIG. 8 illustrates an example vital signs interface for the medicaldevice of FIG. 3.

FIG. 9 illustrates an example interface for the medical device of FIG.3.

FIG. 10 illustrates another view of the interface of FIG. 9.

FIG. 11 illustrates another view of the interface of FIG. 9.

FIG. 12 illustrates another view of the interface of FIG. 9.

FIG. 13 illustrates another view of the interface of FIG. 9.

FIG. 14 illustrates another view of the interface of FIG. 9.

FIG. 15 is a block diagram illustrating physical components of acomputing device with which examples and embodiments of the disclosurecan be practiced.

DETAILED DESCRIPTION

Examples of ambulatory care environments can include hospitals, clinics,managed care facilities, and other locations where medical care isprovided. Medical personnel in ambulatory care environments can utilizevital signs monitoring devices, vital signs displays, personal computingdevices and electronic medical record access portals. Medical staff andproviders often need to record a patient's vital signs and enter thosevital signs into the patient's electronic medical record. Currently,providers must perform vital signs measurements, remember themeasurements, and then enter those measurements into one or morecomputing devices which may or may not be directly linked to thepatient's electronic medical record.

FIG. 1 illustrates a block diagram of an example wireless ambulatorycare network 100. The example network 100 includes medical devices 103and 104, wireless computing devices 108 and 109, and communicationnetwork 110. In embodiments, the example network 100 can include more orfewer medical devices 103 and 104. In embodiments, the example networkcan include more or fewer wireless computing devices 108 and 109. Thecommunication network 110 can be a wireless network, such as WiFi,Bluetooth, Zigbee, Ant, Z-Wave, etc.

In some embodiments, the one or more medical devices 103 and 104 caninclude one or more vital signs measurement components. For example, themedical devices 103 can include, for example, a thermometer, a heartrate monitor, a pulse oximeter, a non-invasive blood pressure monitor,and a respiration rate monitor. In embodiments, one or more vital signsmeasurement components are wirelessly linked to the medical devices 103and 104 and can transmit measurements to the medical devices 103 and104.

Example computing components of medical devices 103 and 104 are shownand described in more detail with reference to FIG. 15, below.

In some embodiments, the one or more wireless computing devices 108 and109 can be smart phones, tablet computers, personal digital assistants,laptop computers, and desktop computers, which can optionally be mountedon portable carts. Example computing components of the one or morewireless computing devices 108 and 109 are shown and described in moredetail with reference to FIG. 15, below. The use of less complicatedwireless computing devices 108 and 109, such as heart rate monitors,pulse oximeters, etc., is also contemplated by this document.

FIG. 2 illustrates one example of the medical device 105. The medicaldevice 105 is shown on a mobile cart, and the medical device 105 isprogrammed to provide the functionalities described herein. The medicaldevice 105 includes a user interface, such as a touch screen, andincludes the ability to execute multiple workflows or profiles. In someembodiments, the medical devices 105 and 106 in FIGS. 2 and 3 are themedical device 103 or 104 shown in, and described with reference to,FIG. 1. Other embodiments can include more or fewer components thanthose shown in FIG. 2, or include different components that accomplishthe same or a similar function.

The medical device 105 is able to operate within one or more profiles. Aprofile is a series of one or more tasks that a user of the medicaldevice 105 performs. When the medical device 105 operates within aprofile, the medical device 105 provides functionality suitable forassisting the user in performing the profile. When the medical device105 operates within different profiles, the medical device 105 providesdifferent functionality.

When the medical device 105 is manufactured, the medical device 105 isconfigured to be able to operate within one or more profiles. After themedical device 105 is manufactured, the medical device 105 can bereconfigured to operate within one or more additional profiles. In thisway, a user can adapt the medical device 105 for use in differentprofiles as needed.

In various embodiments, the medical device 105 operates within variousprofiles. For example, in some embodiments, the medical device 105 canoperate within a monitoring profile or a non-monitoring profile. Exampletypes of non-monitoring profiles include, but are not limited to, a spotcheck profile and an office profile. An example of a monitoring profileincludes, but is not limited to, an intervals profile.

An additional example of the medical device 106 is shown in FIG. 3. Inthis example, the medical device 106 is similar to that of the medicaldevice 105 described above. In embodiments, the medical device 106 ismounted on a wall. The medical device 106 is programmed in a mannersimilar to that described above to monitor physiological parameters of apatient. In some embodiments, the medical device 106 is a stand-alonedevice, which can mean that is not part of a mobile cart and it is notpart of a wall-mounted station.

In the examples described herein, the medical devices 104, 105, 106 arecomputing devices that have been programmed to perform special, complexfunctions. These specially-programmed devices function to manipulate andprovide data to the users in an improved form factor and with greaterefficiency.

For example, as described further below, the medical devices 104, 105,106 are specially programmed to provide the user with an improvedinterface during initial use of the devices. This allows the user tomore efficiently select a profile for controlling the functionality ofthe device.

In addition, the medical devices 104, 105, 106 are specially programmedto assist the users once vital signs information is captured from thepatients. For example, the devices are programmed to more efficientlyand easily capture additional contextual information that is needed whensaving vital signs data to a permanent record, such as an EMR record.This is accomplished using an interface that is more intuitive androbust.

Referring now to FIGS. 4-8, an example interface 200 for allowing a userto login to and select a profile for the medical devices 104, 105, 106is shown.

In FIG. 4, the interface 200 includes a login area 202 and a profileselection area 204. The login area 202 collects information to assist inthe identification of the user. This information includes a clinicianidentifier (ID) and a password. In other examples, different informationcan be collected, such as a user name or badge number. Any otheridentification information can also be captured as desired. The user canenter the identification information into the device using an inputdevice such as a keyboard, touchscreen, mouse, scanner, etc.

Referring now to FIG. 5, once the user's identification information(i.e., clinician ID and password) is provided, the device confirms thecredentials. This can be completed locally (i.e., by the device itself)and/or by accessing information on the network 110.

In FIG. 6, the user's identification information has been confirmed. Atthis point, the profile selection area 204 is now active. The profileselection area 204 generally provides information about the differentprofiles that can be implemented by the device. In the example given,the device can operate using one of three profiles: spot, office, orinterval.

Each of the profiles includes a separate area 206, 208, 210 that allowsfor contextual information to be provided about that profile. Forexample, the spot area 206 includes the name of the profile and adescription of what is accomplished using the profile. This descriptioncan include such information as: (i) data acquisition—what vital signsdata is collected for the profile; (ii) data retention—how that vitalsigns data is stored, such as in duration; (iii) patient identificationretention—how patient-specific information is retained by the device;etc. In some examples, the description is a textual string (e.g., aseries of sentences and/or one or more paragraphs) that describe, inprose form, how the profile functions.

In this example, the spot profile is a non-monitoring profile, and thedescription can provide information to the user such as: a customizedlabel describing the facility's preferred term for the workflow such as“Rounds”, “Vitals”, “Observations”, a customized description such as,“For single-reading use on multiple patients,” or “Multiple patients perround”, and a customized icon to provide visual recognition of theworkflow. Similar language can be provided in the office area 208 (e.g.,a customized label describing the facility's preferred term for theworkflow such as “Vitals”, “Exams”, or “Readings”, a customizeddescription such as, “For use on routine exams”, and a customized iconto provide visual recognition of the workflow) and interval area 210(e.g., a customized label describing the facility's preferred term forthe workflow such as “Interval Monitoring”, “Intervals”, “BedsideObservations”, a customized description such as, “For multiple readingson single patients” or “Single patient monitoring”, and a customizedicon to provide visual recognition of the workflow) to allow the user tomake an educated decision on how to configure the device before thedevice is used. The user can select one of the areas 206, 208, 210 asdesired using an input device (e.g., keyboard, mouse or touch) to startthe device in that profile.

In FIG. 7, once the profile is selected, the user must identify thepatient. In this example, a box 211 is presented to the user, and theuser can identify the patient using various methods, such as by scanninga patient identification tag.

Once the profile is selected and the patient is identified, the user isprovided with an interface 220, as shown in FIG. 8. This interface 220can be used to capture vital signs information, such as that shown inFIGS. 2-3.

In the example shown, more or fewer profile areas can be shown. In someembodiments, the profile areas are configurable depending on the type ofdevice and/or the type of use for the device. For example, a particularfacility (e.g., hospital or clinic) can tailor the profiles to thoseused at that facility, as well as tailor the description of thoseprofiles to use vernacular that is more easily understood at the givenfacility. In this manner, the user is provided with the relevantprofiles, and each profile area provides additional context so that theuser can make the proper selection of the desired profile before vitalcapture.

In the shown embodiment, the login area 202 includes a control(“Continue without login”) that allows a user to use the medical devicewithout providing login credentials. Such functionality could be used,for example, in an emergency situation where the time required toprovide those credentials could compromise patient health. However, ifthe medical device is accessed in this manner, some of the functionalityof the medical device can be limited or otherwise modified. For example,the medical device may not allow any vital signs data to be recorded toan EMR until the user provides the necessary credentials. Otherconfigurations are possible.

Referring now to FIGS. 9-14, an example interface 320 for capturingadditional data upon saving of vital signs information by the medicaldevices 104, 105, 106 is shown. In these examples, the additional datacan include parameters associated with the vitals data that is collectedand stored by the medical device. Examples of this data include inputsfor text, integers, decimals, lists, and modifiers (a custom inputbecomes a modifier if an association is established between the inputand a parameter on the device during configuration). All custom inputscan have input ranges specified and validation rules established.Example custom inputs include, without limitation, Capillary Refill Time(CRT), Glucose, Glasgow Coma Score, Urine Output, Cuff Size, O2 FlowRate, O2 concentration, Measurement Site, etc. The interface 320 allowsfor the sequential capture of this information in an easy-to-use andefficient manner.

At FIG. 9, the interface 320 is shown displaying captured vital signsdata, including NIBP, Pulse Rate, SpO2, and Temperature. As noted, theseare only examples, and other vital signs data can also be captured anddisplayed. Once capture of the vital signs data is complete, the userselects a next button 328 to record the vital signs data to, forexample, an EMR.

FIG. 10 shows additional parameters areas 322, 324, 326 that aredisplayed when the user selects the next button 328 on the interface320. These additional parameter areas 322, 324, 326 are used to capturefurther information that is needed when recording the vital signs datato the EMR.

For example, the additional parameter area 322 records an Early WarningScore for the patient. The user selects between Scores 1-3. Theadditional parameter areas 324, 326, capture other parameters, such asCRT, Pain, Respirations, White Cell Count, Respiratory Distress, and/orConscious Level. While three additional parameters are shown, more orfewer can be captured. For example, the additional parameters that areobtained can be tailored to the vital signs information that is capturedby the device and shown on the interface 320.

Once the user provides the information required in each of theadditional parameters areas 322, 324, 326, the next button 328 becomeactive, as shown in FIG. 11. In this example, the user must provide eachadditional parameter or affirmatively skip one or more of the parameters(see FIG. 14) before the next button 328 become active.

Once the next button 328 is selected, a summary of the additionalparameters is provided to the user on an interface 332 at FIG. 12. Thisallows the user to review the additional parameter information foraccuracy. Assuming everything is correct, the user can select the button330 to store the additional parameters.

At FIG. 13, the interface 320 is again shown. In this context, the nextbutton 328 is removed, and a save button 342 is provided. Once selectedby the user, the save button 342 causes the vital signs data andadditional parameters to be saved, for example, locally and/or to an EMRrecord across the network 110.

Referring again to FIGS. 10-11, the additional parameter areas 322, 324,326 can also include skip buttons that allow the user to avoid providingone or more of the additional parameters. If a skip button is pressed,the user is presented with an interface 350 shown in FIG. 14. Theexample interface 350 indicates that the particular facility requiresthat the additional parameter be recorded. If the user selects the “OK”button, recordation of the parameter is overridden, and the override isrecorded (e.g., such information as user name and time). If the userselects “Cancel”, the user has the opportunity to provide the additionalparameter on the appropriate area 322, 324, 326.

In these examples, whether or not the additional parameters are requiredcan be configured based upon device and/or facility preferences. Forexample, a facility can decide which additional parameters must becaptured for certain vital signs data recordations. These parameters canbe required before the user is allowed to record the information in theEMR. In other examples, the information can be recorded even if one ormore of the additional parameters are skipped. Other configurations arepossible.

FIG. 15 is a block diagram illustrating physical components (i.e.,hardware) of a computing device 1800 with which embodiments of thedisclosure may be practiced. The computing device components describedbelow may be suitable to act as the computing devices described above,such as wireless computing device and/or medical device of FIG. 1. In abasic configuration, the computing device 1800 may include at least oneprocessing unit 1802 and a system memory 1804. Depending on theconfiguration and type of computing device, the system memory 1804 maycomprise, but is not limited to, volatile storage (e.g., random accessmemory), non-volatile storage (e.g., read-only memory), flash memory, orany combination of such memories. The system memory 1804 may include anoperating system 1805 and one or more program modules 1806 suitable forrunning software applications 1820. The operating system 1805, forexample, may be suitable for controlling the operation of the computingdevice 1800. Furthermore, embodiments of the disclosure may be practicedin conjunction with a graphics library, other operating systems, or anyother application program and is not limited to any particularapplication or system. This basic configuration is illustrated in FIG.15 by those components within a dashed line 1808. The computing device1800 may have additional features or functionality. For example, thecomputing device 1800 may also include additional data storage devices(removable and/or non-removable) such as, for example, magnetic disks,optical disks, or tape. Such additional storage is illustrated in FIG.15 by a removable storage device 1809 and a non-removable storage device1810.

Other program modules that may be used in accordance with embodiments ofthe present disclosure, and in particular to generate screen content,may include electronic mail and contacts applications, word processingapplications, spreadsheet applications, database applications, slidepresentation applications, drawing or computer-aided applicationprograms, etc.

Furthermore, embodiments of the disclosure may be practiced in anelectrical circuit comprising discrete electronic elements, packaged orintegrated electronic chips containing logic gates, a circuit utilizinga microprocessor, or on a single chip containing electronic elements ormicroprocessors. For example, embodiments of the disclosure may bepracticed via a system-on-a-chip (SOC) where each or many of thecomponents illustrated in FIG. 15 may be integrated onto a singleintegrated circuit. Such an SOC device may include one or moreprocessing units, graphics units, communications units, systemvirtualization units and various application functionality all of whichare integrated (or “burned”) onto the chip substrate as a singleintegrated circuit. Embodiments of the disclosure may also be practicedusing other technologies capable of performing logical operations suchas, for example, AND, OR, and NOT, including but not limited tomechanical, optical, fluidic, and quantum technologies. In addition,embodiments of the disclosure may be practiced within a general purposecomputer or in any other circuits or systems.

The computing device 1800 may also have one or more input device(s) 1812such as a keyboard, a mouse, a pen, a sound or voice input device, atouch or swipe input device, etc. The output device(s) 1814 such as adisplay, speakers, a printer, etc. may also be included. Theaforementioned devices are examples and others may be used. Thecomputing device 1800 may include one or more communication connections1816 allowing communications with other computing devices 1818. Examplesof suitable communication connections 1816 include, but are not limitedto, RF transmitter, receiver, and/or transceiver circuitry; universalserial bus (USB), parallel, and/or serial ports. Additionally, thecommunication connections 1816 can include a Bluetooth Low Energy Radio.

The term computer readable media as used herein may includenon-transitory computer storage media. Computer storage media mayinclude volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information, suchas computer readable instructions, data structures, or program modules.The system memory 1804, the removable storage device 1809, and thenon-removable storage device 1810 are all computer storage mediaexamples (i.e., memory storage.) Computer storage media may include RAM,ROM, electrically erasable read-only memory (EEPROM), flash memory orother memory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other article ofmanufacture which can be used to store information and which can beaccessed by the computing device 1800. Any such computer storage mediamay be part of the computing device 1800. Computer storage media doesnot include a carrier wave or other propagated or modulated data signal.

Communication media may be embodied by computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as a carrier wave or other transport mechanism, andincludes any information delivery media. The term “modulated datasignal” may describe a signal that has one or more characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communication media may includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), infrared, andother wireless media.

Embodiments of the present disclosure may be utilized in variousdistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network in adistributed computing environment.

The logical flows depicted herein are just examples. There may be manyvariations to these diagrams or the steps (or operations) describedtherein without departing from the spirit of the disclosure. Forinstance, the steps may be performed in a differing order, or steps maybe added, deleted or modified.

While embodiments have been described, it will be understood that thoseskilled in the art, both now and in the future, may make variousimprovements and enhancements can be made.

What is claimed is:
 1. A method for displaying information and receivinginputs with a medical device, the method comprising: displaying a firstinterface on a display of the medical device, wherein the firstinterface comprises: a login area including one or more prompts forinformation identifying a user of the medical device; and a profileselection area including two or more profiles offered by the medicaldevice, wherein each of the profiles is a series of tasks to beperformed by the medical device, and a description of each profile isprovided in the profile selection area; receiving user identifyinginformation from the user via the login area; confirming the useridentifying information; activating the profile selection area inresponse to confirming the user identifying information; receiving aprofile selection from the user via the profile selection area;receiving patient identification information from the user with themedical device; displaying a second interface on the display of themedical device; and receiving vital signs data from the patient usingthe second interface.
 2. The method of claim 1, wherein displaying thelogin area of the first interface comprises displaying at least oneprompt selected from the group consisting of a clinician identifier, apassword, a user name and a badge number.
 3. The method of claim 1,wherein receiving user identifying information comprises receiving theidentifying information entered by the user using an input deviceselected from the group consisting of a touchscreen, a keyboard, a mouseand a scanner.
 4. The method of claim 1, wherein the user identifyinginformation must be confirmed before the user can select one of the twoor more profiles in the profile selection area.
 5. The method of claim1, wherein the medical device confirms the identifying informationlocally, at the medical device.
 6. The method of claim 1, wherein thetwo or more profiles of the displayed profile selection area comprise: aspot profile; an office profile; and an interval profile.
 7. The methodof claim 1, wherein the description in the profile selection area foreach of the two or more profiles includes a prose description of afunctionality associated with each respective profile.
 8. The method ofclaim 1, further comprising displaying a patient identification box onthe display of the medical device, after receiving the profile selectionfrom the user, to prompt the user to input the patient identificationinformation.
 9. The method of claim 1, wherein displaying the firstinterface further comprises displaying a control that allows the user touse the medical device with limited functionality without providinglogin credentials in an emergency situation.
 10. A method for displayinginformation and receiving inputs with a medical device, the methodcomprising: displaying a first interface on a display of the medicaldevice, wherein the first interface comprises: a login area includingone or more prompts for information identifying a user of the medicaldevice; and a profile selection area including two or more profilesoffered by the medical device, wherein each of the profiles is a seriesof tasks to be performed by the medical device, and a description ofeach profile is provided in the profile selection area; receiving useridentifying information, a profile selection and patient identificationinformation from the user of the medical device; displaying a secondinterface on the display of the medical device, wherein the secondinterface is configured to capture vital signs data of a patient andincludes a first next button; and displaying a third interface on thedisplay, wherein the third interface includes multiple additionalparameter areas and a second next button, and wherein the multipleadditional parameter areas are configured to capture one or moreadditional parameters associated with the vital signs data captured withthe second interface.
 11. The method of claim 10, further comprising:confirming the user identifying information; activating the profileselection area in response to confirming the user identifyinginformation; and receiving the vital signs data from the patient usingthe second interface.
 12. The method of claim 10, wherein theidentifying information must be confirmed before the user can select oneof the two or more profiles in the profile selection area.
 13. Themethod of claim 10, wherein one of the multiple additional parameterareas of the third interface records an early warning score for thepatient, and wherein at least one of the multiple additional parameterareas includes a skip button.
 14. The method of claim 10, wherein theadditional parameter areas include multiple separate areas, and whereineach of the multiple separate areas is configured to capture one of theadditional parameters.
 15. The method of claim 14, wherein each of themultiple separate areas includes a control, which allows the user toskip providing the respective additional parameter associated with therespective separate area.
 16. The method of claim 15, further comprisingdisplaying a prompt area when the user selects the control to skipproviding the respective additional parameter, the prompt area includinginstructions on providing the additional parameter.
 17. The method ofclaim 16, further comprising recording, with the medical device, whenthe user decides to skip one or more of the additional parameters. 18.The method of claim 10, further comprising activating a control used tosave data associated with recorded vital signs data and the additionalparameters when the user provides the additional parameters.
 19. Themethod of claim 10, wherein the two or more profiles of the displayedprofile selection area comprise: a spot profile; an office profile; andan interval profile.
 20. The method of claim 10, wherein the descriptionin the profile selection area for each of the two or more profilesincludes a prose description of a functionality associated with eachrespective profile.